Computing environments are capable of executing computer code that contains one or more instructions for the computing environment's hardware components to perform one or more operation. Typically computer code is loaded onto a computing environment for execution. Prior to the physical loading, the computer code can be compiled so that it operates on a particular computing environment (e.g., a computing environment's operating system and/or a computing environment's platform). The computer code can be linked by the computing environment with other computer code residing on the computing environment to execute one or more operations. Depending on the computing environment handling of given computer code, a binary object can be created for use by the computing environment and/or other cooperating computer code. The binary object may contain information, functions, and/or operations desired by one or more cooperating computing programs (computing programs).
One or more functions, in turn, can be aggregated in one or more libraries for use by computing applications, other libraries, or by a computing environment to perform one or more operations. In a general practice, a library is designed and implemented such that it can be utilized by a singular computing environment having a specific hardware architecture. The library can be utilized by a given computing environment on either a static basis or on a dynamic basis. In the static context, the libraries and other components of a given computing application are combined into a single file which can be loaded into memory and executed. Comparatively, with dynamic operations (e.g., dynamic linking of components) functions and components (e.g., objects and libraries) are made available when a computing application is executed. Dynamic components can be shared by several computing applications operating on a computing environment since dynamically linked components, in their design and operation, are not tied to a main part of a computing application.
However, current practices can be cumbersome when creating and executing computer code for operation on disparate computing environments. Since current practices generally require the creation and execution of computer code for a specific computing environment (e.g., through a software development kit—SDK) having a particular computing hardware architecture, it can be difficult to create a single binary object for operation on a number of disparate computing environments (e.g., having various operating systems and/or computing platforms). When creating code for a particular computing environment, the computer code can be compiled in advance of loading it onto the computing environment and can be linked by the computing environment when executing the computer code. With these constraints, computer code is generally designed and created to operate on a singular computing environment (i.e. operating system and/or platform).
Additionally, computing environments can impose constraints and rules on the manner in which computer code should be created so that it can properly execute on a given computing environment. For example, a platform and/or operating system (e.g., SymbianOS running Symbian Quartz) can maintain a number of constraints on computer code being executed on the particular platform and/or operating system, including but not limited to, the use of writeable static and/or global variables. Stated differently, the platform and/or operating system can forbid the operation of computer code having writeable static, or global variables.
A common practice among computer code developers includes, but is not limited to, developing various code performing the same operations but built for each of a disparate set of operating systems and platforms. For example, a calendaring computing application can be developed using a single high level programming language such as Java, “C++”, or Visual Basic. In an effort to reduce development time and resources, core computing application code can be reused by developers. However, the extent of such reuse is limited since with current practices additional components (e.g., libraries, functions, data structures, etc.) need to be developed and customized to ensure that the computing application is operable on each of a set of disparate computing environments (e.g., operating systems and/or platforms).
Conventional practices and approaches have other limitations including, but not limited to, an inability of having a single platform independent binary object that can be operable across a plurality of disparate computing environments without requiring rebuilding or recompiling for each of the disparate computing environments. Additionally, current practices and approaches do not offer a mechanism for dynamically linking shared objects on platforms that do not offer such native facility. Also, with current practices, pre-written code components can not be utilized on platforms that otherwise would be incompatible due to a violation of platform constraints within particular code. Further, current practices do not offer a mechanism for loading non object-oriented code that circumvents restrictions of multiple execution instances and repeat execution inherent in the code. Also, current practices and approaches do not offer a mechanism that allows for the dynamic linking and loading of a binary object on a closed platform (e.g., a platform that may restrict the execution of additional programs).